home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14752 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.5 KB  |  64 lines
  1. Path: news.vanderbilt.edu!news
  2. From: haseltbt@ctrvax.vanderbilt.edu (Bennett Haselton)
  3. Newsgroups: comp.lang.c++
  4. Subject: Turbo 3.0 compiler bug -- I MEAN IT!!!!
  5. Date: 1 Apr 1996 23:35:04 GMT
  6. Organization: Vanderbilt University
  7. Message-ID: <4jpp78$85b@news.vanderbilt.edu>
  8. NNTP-Posting-Host: dial094.vanderbilt.edu
  9. Mime-Version: 1.0
  10. Content-Type: Text/Plain; charset=ISO-8859-1
  11. X-Newsreader: WinVN 0.99.5
  12.  
  13.  
  14.     Hello world,
  15.  
  16.         i've found what appears to be a bug in the Turbo 3.0 C++ 
  17. compiler.  Apparently if you write a while loop that is immediately preceded by 
  18. code identical to that contained in the while loop--and the "while" statement 
  19. is true at the time the code immediately preceding it is analyzed--then the 
  20. compiler ignores this extra code preceding the while loop as unnecessary.  
  21. Seems reasonable--equivalent output, right?
  22.     The problem is in the debugging process.  i had written code with the 
  23. above-mentioned redundancy to make it easier to read, and in the debugging 
  24. cycle i tried setting breakpoints within the block of "redundant" code.  Turbo 
  25. C++ will not allow breakpoints to be set at empty or commented space; 
  26. unfortunately the redundant code was compiled as "empty space" and breakpoints 
  27. were forbidden there.  Worse, when the compiler skipped to a breakpoint inside 
  28. the while loop, it became obvious from the values of watch variables that the 
  29. redundant code had been skipped entirely.
  30.     For example:
  31.  
  32. void main()
  33. {
  34.     int i, j, k;
  35.     ++i;        // (1)
  36.     ++j;        // (2)
  37.     ++k;        // (3)
  38.     while ( i < 5 )
  39.     {
  40.         ++i;    // (4)
  41.         ++j;    // (5)
  42.         ++k;    // (6)
  43.     }
  44. }
  45.     During debugging, if breakpoints are set at lines 1, 2, or 3, they will 
  46. generate "invalid breakpoint" messages because this code is apparently ignored. 
  47. If you comment out line (4), for example, then the compiler will allow a 
  48. breakpoint to be set at line (1), because it is no longer redundant, but not at 
  49. lines (2) or (3).  Commenting out lines (4) and (5) together produces similar 
  50. results.
  51.     Although the code i wrote contained such a redundancy because it was 
  52. easier to follow that way, a redundancy is not the same as an error, and even 
  53. though the compilation is more efficient, for the purposes of debugging, the 
  54. program may have been better off without this automated streamlining.  If you 
  55. have all known about this anomaly of Turbo 3.0 for a while, sorry about 
  56. wasting the bandwidth but it is the first bug i have ever discovered in a 
  57. non-Microsoft application costing > $100 and it was just something i felt 
  58. compelled to share :-).
  59.     Bleep,
  60.  
  61.             tm
  62.     -bennett haselton
  63.  
  64.